next.js가 느려졌다?!! | 매거진에 참여하세요

Next.js, 그리고 성능 이슈

Next.js는 React 기반 웹 개발에서 빠르고 SEO 친화적인 경험을 제공하며 널리 사용되고 있습니다.

2024년 10월 기준, Apple, TikTok, Spotify 등 주요 플랫폼에서 채택 중입니다

그러나 최근 2025년 들어 대형 서비스 또는 복잡한 기능을 사용하는 프로젝트들에서 “다음에서 느려졌다”는 목소리가 늘어나고 있습니다.

실제 사례: “왜 대형 서비스가 Next.js를 버렸나”

Northflank는 Next.js로 구성된 마케팅/도큐멘테이션 사이트에서 SSR 성능이 크게 떨어져,

자체 React + Express SSR 솔루션으로 교체했고, 페이지 렌더링 성능은 700ms → 20ms 수준으로 30배 이상 향상했다고 전했습니다

• * next.js 업데이트 방향

버전	출시 시기	주요 기능/변화 내용
Next.js 12	2021년 10월	- Middleware 도입 (Edge에서 코드 실행 가능) - ES Modules 지원 - SWC 컴파일러 기본 채택 (Babel 대체, 속도 ↑) - URL 기반 로딩 (ESM 기반) - NEX/IMAGEnext/image 개선
Next.js 13	2022년 10월	- App Router 도입 (Pages 기반에서 벗어난 폴더 기반 라우팅) - React Server Components (RSC) 지원 - Streaming Rendering via @vercel@vercel/og - Layouts, Templates 개념 도입 - 새로운 디렉토리 구조
Next.js 14	2023년 10월	- Partial Prerendering (PPR) 실험적 도입 - Turbopack 개선 및 안정화 (Webpack 대체 목표) - View Transitions API 실험적 지원 - 서버/클라이언트 컴포넌트 명확화 - next/fontn자동 최적화 향상
Next.js 15	2024년 5월 (beta), 2024년 6월 (정식 예정)	- Turbopack 정식 기본 빌드 시스템 - Dynamic OG Image Generation 개선 - RSC, Suspense, Streaming Rendering 기본 내장 강화 - Better Dev Server & Fast Refresh 속도 개선 - Edge 기능 강화 및 세분화된 캐시 제어

왜 느려졌을까?

1. 1. App Router + Server Components → 학습 곡선 + 성능 혼란

Next.js 13부터 도입된 App Router와 React Server Components(RSC)는 명확한 렌더링 흐름을 어렵게 만들었습니다.

SSR, CSR, ISR, RSC, Streaming이 혼합되면서 렌더링 타이밍이나 hydration 위치를 예측하기 어려워졌죠.

• - 클라이언트에서 렌더되던 일부 요소가 서버로 옮겨가면서 비동기 컴포넌트 로딩 지연

• - RSC 도입 시 useEffect가 동작하지 않아 다시 CSR로 되돌아가는 경우 발생

• “Client component로 바꾸세요” 경고로 인해 개발자 경험 자체가 느리게 느껴짐

실제로 개발자들은 RSC로 빌드할 때 React Suspense의 동작을 이해하지 못해 렌더링 지연, 로딩 중 깜빡임, 심지어 빌드 실패 등을 겪고 있습니다.

2. 2. Turbopack 전환기 → 불안정한 개발 환경 속도

Next.js는 Webpack에서 Rust 기반의 Turbopack으로 전환 중입니다.

초기에는 빠르다는 평가를 받았지만:

• - 대규모 프로젝트에서는 CPU 점유율 급증, 파일 변경 후 빌드 시간 지연

• - 완전한 Webpack 호환이 안 돼 기존 설정을 재작성해야 함

• - 개발 서버(Dev server) 성능이 일정치 않아 핫리로드 지연 발생

일부 커뮤니티에서는 “Webpack보다 오히려 느려졌고, 릴로드 속도도 줄었다”는 보고가 나오기도 했습니다.

3. 정적 생성에 집착한 전략 → 실시간 UX 요구에 부딪힘

Next.js는 기본적으로 , getStaticPros중심의 정적 생성 중심 철학을 가집니다.

하지만실시간 개인화, 다국어 대응, 사용자 세션 기반 콘텐츠가 늘어나면서 정적 페이지로는 대응 한계

• ISR(Incremental Static Regeneration)은 fallback 처리 이슈로 복잡성 유발

• 결국 SSR로 전환 → 페이지 렌더링 속도 저하

예: “접속자에 따라 콘텐츠가 바뀌는 페이지”에서 정적 생성이 무용지물이 되면서

SSR로 바꾸면 TBT, LCP 지표 악화로 Core Web Vitals 점수가 떨어지게 됨

4. 모듈 크기와 의존성의 급격한 팽창

Next.js는 기본적으로 많은 모듈을 자동 번들링 해주지만, 앱 크기가 커지면 다음 문제가 발생합니다:

기본 템플릿 복잡도 증가

• 폰트, 이미지, 스타일을 모두 최적화하려다 오히려 최초 렌더 지연 발생

• 1MB 이상 JS bundle이 발생하기도 하며, hydration이 지연됨

5. 서버와 엣지 사이의 선택 압박

Next.js는 이제 Vercel을 중심으로 Edge-first 아키텍처를 강조합니다.

하지만:

• - Edge function은 cold start, 제한된 실행 시간, 제한된 환경 (예: no native Node module)

• - 서버와 엣지 기능이 동시에 섞인 프로젝트에서는 캐싱 전략 설정 어려움 → 예측 불가한 지연 발생

• - 로컬 개발 시 Edge 환경을 정확히 시뮬레이션하지 못함

6. “기능이 많아서” 느린 것이 아니라 “기능을 잘못 썼을 때” 느려진다

많은 개발자들이 느끼는 "느려졌다"는 감정은 사실 다음과 같은 경우입니다:

• - SSG로 해결될 페이지에 SSR을 걸어버림

• - use client 필요한데 하지 않음 → hydration 지연

• - Suspense로 async 컴포넌트 감싸지 않음 → fallback delay

• - router 또는 middleware에서 캐싱 전략을 설정하지 않음

• - Turbopack을 도입했지만 Webpack 설정을 그대로 사용

즉, 프레임워크 자체의 성능 문제라기보다는, 새롭게 도입된 기능을 적절히 조합하지 못해서 생기는 지연 현상이 많습니다.

“느리다”는 오해인가? – 장단점 균형

“Next.js는 여전히 강력한 퍼포먼스 툴이 많으며, 제대로 활용하면 빠릅니다.

하이브리드 렌더링, 캐시, 동시 데이터 패치, Suspense, next/image 등을 잘 쓰면 느리다는 인식은 해소될 수 있다고 말합니다

즉, 도구 자체의 한계가 아니라, 잘못된 설정과 사용 방식이 문제입니다.

Dev performance note by BUNZEE